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Abstract 


This is the final report on the research performed under NASA Glen grant NASA/NAG- 
3-1975 concerning feedback control of the Pratt & Whitney (PW) STF 952, a twin spool, 
mixed flow, after burning turbofan engine. The research focussed on the design of linear 
and gain-scheduled, multivariable inner-loop controllers for the PW turbofan engine using 
i/oo and linear, parameter-varying (LPV) control techniques. The nonlinear turbofan engine 
simulation was provided by Pratt & Whitney within the NASA ROCETS simulation soft- 
ware environment. ROCETS was used to generate linearized models of the turbofan engine 
for control design and analysis as well as the simulation environment to evaluate the perfor- 
mance and robustness of the controllers. Comparison between the "Hoo and LPV controllers 
are made with the baseline multivariable controller and developed by Pratt & Whitney en- 
gineers included in the ROCETS simulation. Simulation results indicate that and LPV 
techniques effectively achieve desired response characteristics with minimal cross coupling 
between commanded values and are very robust to unmodeled dynamics and sensor noise. 
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Chapter 1 


Introduction 


The design of traditional gain-scheduled, inner-loop controllers for a turbofan engine takes 
significant time and can not guarantee performance and stability of the closed-loop system 
across the operating envelope [10]. Linear parameter-varying (LPV) control methodologies 
can however, guarantee stability and performance over the entire operating envelope, making 
them a natural approach for inner-loop control of turbofan engines. This report documents 
the application of LPV control design techniques to a PW turbofan engine. Pratt & Whitney 
and NASA Glenn at Lewis Field Research Center provided the University of Minnesota with 
a transient turbofan engine simulation (ROCETS) to use as a test bed for implementing LPV 
control designs. The baseline multivariable control algorithm in ROCETS was implemented 
as many interconnected subroutines rather than as a single integrated subroutine. This was 
not conducive to implementation and simulation of candidate controllers, and necessitated 
changes to the controller software implementation in ROCETS. This report discusses the 
revisions required to implement state-space and LPV controllers, the design of 'Hoo &nd LPV 
controllers, and the results obtained from the implementation of the controllers in the Pratt 
& Whitney engine simulation. 


1.1 Accomplishments 

This grant partially supported the turbofan engine control research of Professors Gary Balas 
and William Garrard, a post-doctoral researcher. Dr. Greg Wolodkin, two graduate students. 
Jack Ryan and Dr. Jeff Barker, and two undergraduate researchers, Chris Mitchell and 
Edward Harper. Dr. Wolodkin currently works at the Mathworks and was one of their lead 
engineers in the advanced controls area. He has since moved within the Mathworks and 
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is currently responsible for the core Matlab product. Dr. Barker graduated with the Ph.D. 
degree in 1999 and is employed by Boeing Phantom Works in St. Louis. Jack Ryan wrote his 
Master’s project report on the turbofan engine research and is currently employed by NASA 
Dryden Flight Research Center as a flight simulation engineer. (Note that Chapters 2, 3 
and 5 of this report are based, in part, on his Master’s report.) Chris Mitchell is currently 
a Ph.D. student in the Aerospace Engineering and Mechanics department at the University 
of Minnesota in fluid mechanics and Edward Harper is currently working as an engineer in 
industry. 

The following are a list of the technical accomplishments achieved with the support of this 
grant. 

• Learned to use the NASA Rocket Engine Transient Simulation (ROCETS) system to 
simulate the turbofan engine model provided by Pratt and Whitney (PW). 

• Development of a linear, parameter-varying (LPV) model of the PW turbofan engine 
for control design. 

• Developed and integrated Fortran subroutines to implement linear and LPV state-space 
controllers into the ROCETS nonlinear simulation. 

• Successfully back engineered the baseline PW multivariable controller. 

• Synthesized robust, linear multivariable lioo controllers and gain-scheduled LPV con- 
troller for the turbofan engine. 

• Successfully implemented these controllers in the ROCETS nonlinear simulation. 

• Achieved performance robustness of the non-rate and rate bounded LPV controllers. 
The LPV controllers were scheduled on a lagged measurement of power code. These 
controllers performed well for a variety of environmental conditions, through the flight 
envelope with and without noisy sensor measurements. 

Three papers and a Masters project report were written on the synthesis of controllers for 
turbofan engine during the length of this contract. A fourth paper is in preparation based 
on the latest results of the gain-scheduled LPV inner-loop controllers for the PW turbofan 
engine model. The technical monitor for this grant was Jonathan Litt, NASA Glenn Research 
Center. 

• G. Wolodkin, G.J. Balas, W.L. Garrard, “Application of parameter-dependent robust 
control synthesis to turbofan engines,” AIAA Journal of Guidance, Dynamics and 
Control , vol. 22, no. 6, 1999, pp. 833-838. 


4 



• G. Wolodkin, G.J. Balas, W.L. Garrard, “Application of Parameter-Dependent Robust 
Control Synthesis to Turbofan Engines,” 36th AIAA Aerospace Sciences Meeting, Reno, 
NV, January, 1998, AIAA-98-0973. 

• G.J. Balas, J. Ryan, J.Y. Shin, W.L. Garrard, “A New Technique for Design of Con- 
trollers for Turbofan Engines,” 34th Joint Propulsion Conference, Session 95-ASME-21, 
Cleveland, OH, July, 1998, AIAA-98-3751. 
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Chapter 2 


Engine Simulation 


The Pratt & Whitney STF 952 (Figure 2.1), a twin spool, mixed flow, after burning turbofan 
engine, is used as the example application in this study. It features a highly loaded, three 
stage fan, a four stage high pressure compressor, an axially staged triangular alignment 
combuster, and an advanced high pressure turbine and low pressure turbine. For later 
reference, the fan inlet is identified as station 2, the high pressure turbine inlet as station 4, 
and the turbine exit guide vane as station 6. The pressures at each station are designated as 
P2, P4, and P6 respectively. A diagram of the engine and the actuator and sensor locations 
is given in Figure 2.1. 

The STF 952 engine is modeled using the NASA Rocket Engine Transient Simulation 
(ROCETS) software. The ROCETS model of the STF 952 engine is fully nonlinear and it 
uses a multivariable integration routine based on a modified Newton- Raphson technique to 
calculate transient responses and steady-state balance. The linearized models of the STF 
952 engine are all generated using ROCETS as are all nonlinear closed-loop simulations. 
Through out this report, we will denote the PW' STF 952 turbofan engine as the “engine” 
or “turbofan engine” in the text. 

The engine dynamics vary with thrust request or “power code,” temperature and external 
air pressure. Air pressure and temperature vary with altitude as well as weather. The 
engine power code varies from 3,000 to 30,000 which corresponds to near idle to military 
power. Initially, the altitude is set at sea level, OK ft, a speed of zero Mach and standard 
atmosphere. The objective of the control system is to accurately track inner-loop commands 
to the engine. 

A turbofan engine transient performance computer model of the SCIP Engine (STF 952A) 
was configured using the NASA Rocket Engine Transient Simulation (ROCETS) system. 
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ROCETS interfaces modular components to generate a full engine simulation in which a run 
processor reads and interprets input to run particular experiments. A multi- variable modified 
Newton-Raphson technique is used for transient integrations and steady-state balances [1] 

Schedules of desired thrust level, altitude, Mach number, or other variables can be input 
to the simulation. The simulation model of engine dynamics generate the necessary overall 
pressure ratio {OPR = P4/P2), engine pressure ratio {EPR = P6/P2) and high pres- 
sure compressor spool speed (N2) requests to meet the scheduled variables. These requests 
(OPRREQ, EPRREQ, N2REQ) are fed to the inner-loop control system which generates the 
required primary burner fuel flow (WFPRIB), high pressure compressor normalized variable 
vane angle (VANEHPC), and convergent throat area (AREANOZL) commands to achieve 
the requests. This control inner-loop is the focus of this report. 

The current multivariable controller in the turbofan simulation, used as a baseline to com- 
pare with designed controllers, operates in two modes: start mode and nominal multivariable 
mode. The start mode is used to transition from light off fuel flow, to nominal multivariable 
control mode. The nominal multivariable mode uses a controller scheduled on total corrected 
airflow [1]. This paper focuses on the design of a controller for the nominal multivariable 
mode. The baseline controller is used during the initialization part of the simulation. 

The baseline control interconnection (Figure 2.2) has an two loops. 
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The inner control loop consists of the state space matrix K and the gain matrix S. The A 
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Figure 2.2: Interconnection of Engine Model and Baseline PW Controller 
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( 2 . 2 ) 


The values of j 4 ij, D^ j are determined via a look-up table scheduled on operating 
condition. The states of the controller are: gas generator fuel flow (xi), precursor to the 
normalized gas generator fuel flow (x^), normalized flow parameter(x3), precursor to the 
normalized flow parameter (X4), and normalized compressor variable vane(rc5). 


The inputs to K are 


and 


Ui U2 U 3 ]■ 


(2.3) 


— Cl €2 63 ] 


(2.4) 
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u consists of normalized overall pressure ratio error (iti), normalized engine pressure ratio 
error (u 2 )» and normalized rotor speed error (ua). The vector e consists of overall pressure 
ratio error from the last pass through the loop (ei), engine pressure ratio error from the last 
pass through the loop ( 62 ), and high rotor speed error from the last pass through the loop 

(ea)- 

The outputs from the controller are 

X = [ x\ X 4 X 5 ] (2-5) 


and 

y = [Vi V 2 2 / 3 ]^ (2-6) 

is normalized fuel flow request, y 2 is normalized flow parameter request, and yz is nor- 
malized compressor variable vane request. 


The S matrix has the form 

‘S’2,2'5'3,3 — ‘S'3,25'2,3 ‘S'3,25'1,3 — *S'i,2‘S'3_3 5'i,2'S'2,3 ~ ‘S’2,2*S'l,3 

5'3,i52,3 — 5'2,i 5'3,3 51,153,3 — 53,i5i,3 52,l5i,3 — 5 i,i52,3 

52,i53,2 — 53,i52,2 53,i5i,2 ~ 5i,i52,1 5i,i 52,2 “ 52,l5i,2 

where 

DETGN = 5i i52 253 3 5i, 252, 353,1 -\- 5i,352,l53,2 ~ 53,i52,25i,3 — 53,252,35i,i — 53,352,i5i,2 

( 2 . 8 ) 


1 

DETGN 



It has inputs y\ — a;i, y 2 — 2 : 4 , and yz — Xz, and outputs ei, 62 , and 63 . Together, A and 5 
form the baseline controller for inner-loop control of the PW turbofan engine. 


The closed- loop system consists of the plant model (P), two constant gain matrices (OSC 
and ISC), and the controller. The outer-loop control generates the desired values of overall 
pressure ratio (OPRREQ), engine pressure ratio (EPRREQ), and high speed rotor request 
(N2REQ) based on environmental conditions, power code and the baseline closed-loop engine 
dynamic response. 

The inputs to the plant, P in Figure 2.2, are WFPRIB, VANEHPC, and AREANOZL. The 
plant outputs are P2, P4, P6, and N2. The matrix OSC normalizes its inputs from overall 
pressure ratio error (OPRREQ-OPR), engine pressure ratio error (EPRREQ-EPR) and high 
rotor speed error(N2REQ-N2) to the normalized parameters Ui,U 2 , and uz- The matrix ISC 
dimensionalizes its inputs from yi, y 2 , and yz to WFPRIB, AREANOZL, and VANEHPC. 
The ISC gain matrix is 

■ 7 0 0 

0 807 0 
.00 1 
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and the OSC gain matrix is 


r Q.0320491 
14.55 


0 

0 


0 

Q. 1599723 
14.55 

0 


0 

0 

0.000055528 


2.1 Controller Subroutines 


( 2 . 10 ) 


To implement state-space multivariable controllers, changes were required to the ROCETS 
nonlinear simulation of the turbofan engine model. These modifications allow 3 input, 3 
output multivarible controllers of state order up to 21 to be read in and replace the baseline 
Pratt & Whitney controller. This allowed controllers to be easily tested in the simulation 
without rewriting or recompiling the ROCETS simulation. Changes were also made so that 
the simulation uses the Pratt & Whitney controller in the start up mode until it has reached 
the multivariable control mode. This eliminates engine start-up issues in the design of Hoc, 
and LPV controllers. 

The new code reads in the synthesized controller at the beginning of each simulation. If the 
controller has less than 21 states, it is padded with zeros so that the multiplication routine 
only need work with a constant size control matrix. Figure 2.3 shows the implementation of 
a five state controller in the control algorithm. The usual ABCD five state control matrix 
is located in the bottom right corner. Zeros fill the remaining entries keeping X\ through xig 
constant zeros. Details of the algorithm are presented in Appendix B. 

The ROCETS state-space controller implementation was tested with the Pratt & Whitney 
baseline controller and the results were compared with the original simulation of the PW 
baseline controller implementation. This was necessary to demonstrate our understanding of 
the existing code and our ability to replace the control algorithms with out jeopardizing the 
overall engine simulation. The baseline simulation matched well with the new implementa- 
tion verifying the state-space algorithms. Figure 2.4 compares the Pratt &; Whitney control 
inputs and outputs with our implementation of the Pratt & Whitney controller. Pratt & 
Whitney’s N2 follows its request ramping up after the step input while our implementation’s 
N2 follows its request which does not ramp up. The difference is due to the reference com- 
mand request generating algorithm which is not part of this research project. EPR, OPR 
and N2 commands are treated as exogenous inputs in the control problem since we do not 
have direct control of them. The differences in VANEHPC are directly due to the variations 
in the N2 commands. The small variations in the other channels are not significant. 
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Figure 2.3: Five State Controller in 21 State Framework 
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2.2 Engine Linearized Models 


Ten Jacobian linearized plant models were generated using the nonlinear simulation between 
3000 and 30000 Ibf thrust at 3000 Ibf thrust intervals and different altitudes. Each model was 
generated for a given altitude, zero Mach, zero angle of attack, standard atmosphere, zero 
side slip, and 14.696 psi static pressure. The Jacobian linearizations have 11 states, three 
inputs, and three outputs. The states are identified in Table 2.1, the inputs in Table 2. 2, and 
the outputs in Table 2.3. The simulation’s input file used to generate the linear plants along 
with Matlab utilities to move the generated plants into Matlab files are provided in Appendix 
A. 3 and A. A. 4. 4 respectively. 


State 

Description 

SNl 

Low Rotor Physical Speed (rpm) 

TMCHPC 

High pressure compressor case lumped metal temperature (deg R) 

TMBHPC 

High pressure compressor blade lumped metal temperature (deg R) 

TMRHPC 

High pressure compressor rotor lumped metal temperature (deg R) 

TMCHPT 

High pressure turbine case lumped metal temperature (deg R) 

TMBHPT 

High pressure turbine blade lumped metal temperature (deg R) 

TMRHPT 

High pressure turbine rotor lumped metal temperature (deg R) 

TMCLPT 

Low pressure turbine case lumped metal temperature (deg R) 

TMBLPT 

Low pressure turbine blade lumped metal temperature (deg R) 

TMRLPT 

Low pressure turbine rotor lumped metal temperature (deg R) 

TMILBN 

Main burner liner metal temperature (deg R) 


Table 2.1: Linear Plant States 


Input 

Description 

WFPRIB 

Primary Fuel Flow rate (Ibm/sec) 

VANEHPC 

High pressure compressor normalized variable vane position 

AREANOZL 

Spherical Convergent flap nozzle physical area {iri^) 


Table 2.2: Linear Plant Inputs 

Figure 2.5 shows the magnitude and phase of the linearized plants. The dotted line repre- 
sents the 3000 Ibf model, the solid 15000 Ibf model, and the dash-dot line 30000 Ibf model. 
All other power codes are represented by the dash lines. 

The linearized engine models are used for the T-Loo and LPV control designs. The plots in 
Figure 2.5 indicate that the state order of these models may be reduced. Balanced realization 
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Output 

Description 

P2 

Engine face total pressure (psi) 

P4 

Primary burner exit total pressure (psi) 

P6 

Turbine exit guide vane exit total pressure (psi) 

N2 

High rotor physical speed (rpm) 


Table 2.3: Linear Plant Outputs 

model reduction will be used to reduce the plant state order. Since the LPV design model 
requires all states to have the same meaning, the same balancing transformation matrix 
must be used for all plant models. The transformation matrix at the 12,000 power code was 
selected to balance the models. After balancing, all engine models were truncated to three 
states with no effect on the plant dynamics. 
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Plant Model Magnitude 

WPPRIR AREANOZL VANEHPC 



Plant Model Phase 

WFPRIB AREANOZL VANEHPC 



Figure 2.5: Magnitude (top) and Phase (bottom) of Jacobian Linearizations at Sea Level 
and Standard Day Atmosphere. 
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Chapter 3 

T-Loo Controllers 


Hoo control design techniques are used to synthesize controllers for the PW turbofan at ten 
power code operating points. Jacobian linearizations of the turbofan engine were generated 
at power codes from 3000 to 30000 Ibf thrust in 3000 Ibf increments. The reader is referred 
to references [18, 13, 16] for details on control theory and its application. The con- 
trol objectives were to achieve good tracking of OPR, EPR, and N2 commands, decoupled 
command response, disturbance rejection below 2 rad/sec and a 10 rad/sec bandwidth and 
robustness to modeling error, sensor noise and changing environmental conditions. The Hoc 
controllers also must respect the physical limits on the actuator deflections and rates. The 
controllers are designed using a model matching problem formulation in the Hoc framework 
(see Figure 3.1). We desired the engine to respond as three single-input /single-output (SISO) 
systems with no off-diagonal coupling. P^od represents the decoupled system. Differences 
between this desired model and the true plant are penalized via the weight Wp. 

The disturbance vector di represents customer demands, whose values we wish the plant 
output to track. Specifically these commands correspond to desired normalized overall en- 
gine pressure ratio, normalized engine pressure ratio and normalized high rotor speed. The 
disturbance vector d ,2 is used to represent both noise and input uncertainty in the problem 
formulation to which the controller should be robust. The input uncertainty is mapped to 
the output of the plant model to reduce the number of states required to define the open-loop 
control design interconnection. 

By keeping the error vector ei small, good tracking of is ensured. The role of ea is 
to penalize control effort, in terms of actuator magnitudes as well as actuator rates. The 
controller sees j/c as its input measurements, and generates «c as its output. 
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The actuators are modeled as Pacii ^ diagonal augmentation of unity gain first-order lags, 


Pact — 


100 


s + 100 


hxi 


(3.1) 


The actuator model outputs actuator positions u and actuator rates ii, to allow actuator 
rates to be penalized in the control design. 

The model-matching block Pmod was based on previous work in Reference [2] . It is desired 
that the engine response to OPR and EPR request follow a second order model with natural 
frequency of 10 rad/sec and damping of 0.65. The engine response to I\2 request should 
follow' a second order model with natural frequency of 2.5 rad/sec and damping of 0.65. 
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Here ui = 10 rad/s, u )2 = 2.5 rad/s, and ^ = 0.65. 

The input weight Wi is a constant weighting used to normalize the inputs. The input 
weight 
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in these designs. 

The disturbance is used to model actuator errors as well as limit the bandwidth of 
control effort by ramping up at high frequency. 
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The control weights Wc are selected to be constant. Here we have chosen to penalize the 
normalized actuator movement larger than unity, as well as actuator rates, 
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The performance weight Wp penalizes the difference between the desired and the actual 
closed-loop response of the turbofan engine. The larger the magnitude of Wp, the smaller 
the allowable difference between desired and actual output. In the initial designs, Wp is a 
first order low-pass weight given by 

50o4^ 0 0 

25*+l 

0 300 1^^+^ 0 

r5»+i j 

0 0 400 ^'*'^^ 

This ensures good tracking of the response models in the bandwidth 1-10 rad/s, with little 
or no DC error. At low frequency (below 0.1 rad/s) the Wp weight on the OPR corresponds 
to a DC errors of ^ or 0.2% tracking error. The EPR tracking error at DC is ^ or 0.33% 
and the N2 tracking error at DC can be ^ or 0.25%. At high frequency, the mismatch 
between actual and desired output is not penalized. 

The matrix OSC normalizes its inputs from overall pressure ratio error (OPRREQ-OPR), 
engine pressure ratio error (EPRREQ-EPR) and high rotor speed error(N2REQ-N2). 



Figure 3.1; 'Hoc control design interconnection 


The open-loop interconnection shown in Figure 3.1 has 18 states. Hence the resulting con- 
trollers had 18 states. Eight of the ten Hoc point designs at the power codes between 3K and 
30K achieved an Hoc norm less than 1.62 and all ten were under 2.4. They were first tested in 
linear simulations and then in the nonlinear ROCETS simulation for small step commands. 
While the linear simulations were satisfactory, the nonlinear simulation resulted in highly 
oscillatory reference commands. Recall that the reference commands are generated by an 
outer-loop controller which has not been modified from the original PW baseline design. 
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Figure 3.2 and 3.3, show the ROCETS simulation time response with a linear 'Hoc controller 
implement and a step command from 15000 Ibf to 15100 Ibf. The simulation-generated com- 
mands of OPR, EPR, and N2 are all oscillatory resulting in oscillatory responses. Controllers 
designed for the other nine power codes had similar results. 
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3.1 Identification of Linear Engine Models 


The good performance of the controllers on the linear engine models and the poor 
performance of these controllers in the nonlinear simulation required investigation. The first 
hypothesis was an error in the implementation of the linear state-space controller subroutine 
in ROCETS. After testing, it was found that this was not the case. Therefore, the problem 
must have been related to the inaccuracy of the linearized engine model relative to the 
nonlinear engine simulation. This could be due to several reasons. The first is our poor 
understanding of the ROCETS simulation code. Hence we may have incorrectly linearized 
the engine. Similarly, the ROCETS linearization may only include engine dynamics and 
therefore all the actuator and sensor dynamics, as well as filtering and computational delays 
need to be included in the linear engine model as well. The linear models used in the 
controller synthesis did not capture all the nonlinear plant dynamics. These unmodelled 
dynamics, we conjectured, were causing the oscillations. The linear and nonlinear responses 
of the plant to single channel inputs were therefore examined. 

The nonlinear ROCETS simulation needed to be modified since it was not designed for 
such an examination. By setting two of the three controller outputs to zero, the remaining 
plant input could be set to a variable frequency sinusoidal. Figure 3.4 shows the responses 
to the single sinusoidal inputs. The nonlinear simulation response is represented by the solid 
lines, and the linear models response by the dashed lines. In each set of plots, the top left 
plot displays the active input signal: WFPRIB in the first, AREANOZL in the second, and 
VANEHPC in the third. The remaining plots display the signal responses of OPR, EPR, and 
N2. W'e can see that the linear and nonlinear models do not match exactly. In particular, the 
nonlinear responses of N2 are smoother than their linear counterparts. They respond slower 
and subsequently lack the sharp overshoot. After examining all the controller inputs and 
outputs, to better match the nonlinear engine simulation: the actuator model was modified, 
a sensor model added to the rotor speed sensor, N2, and a lag filter was included in the 
high speed pressure compressor vane actuator, to help slow down the response of N2 and 
compensate for the differences between the linear time response and nonlinear simulation. 
The small signal simulations of the modified linear engine models matched the nonlinear 
engine simulations well across power code at sea level and standard atmosphere. The new 
actuator model was chosen as 
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A sensor model was added to the N2 measurement, 
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sen = 


+ 1 


and a lag filter was added to the N2 command channel, 

lag = Mill 

— s + 1 
12 * ^ 


The modified linear engine models frequency responses are shown in Figure 3.5. The N2 
phase change is apparent as is the VANEHPC input smooth roll off at high frequency. (See 
Figure 2.5 for comparison.). The modified linear models of the engine are used to synthesize 
all the subsequent T^oo LPV control designs. 
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Figure 3.5: Magnitude (top) and Phase (bottom) of Modified Linear Engine Models with 
Lag, Actuator and Sensor Models 
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3.2 Redesigned l-Loo Controllers 


The 7^00 controllers were re-synthesized using the same weights as used in the original 
designs but with the new lag, sensor model and actuator model. The redesigned controllers 
had 20 states and achieved a Hoo norm of 1.54. Time responses in the nonlinear ROCETS 
simulation of the new 15000 Ibf thrust system to a 100 Ibf step are shown in Figure 3.7. The 
oscillations in the reference commands have been eliminated. The 'Hoo controllers achieved 
better tracking than the baseline controller in OPR and EPR, with comparable overshoot. 
Note that with the controller implemented in the nonlinear engine simulation, the re- 
sponse of N2 exhibits more overshoot but better tracking of the N2 command as compared 
with its baseline counterpart. 



Figure 3.6: 1-Loo control design interconnection 
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Chapter 4 


Linear Parameter- Varying Control 
Theory 


We begin with a brief introduction to gain scheduling based on linear parameter-varying 
representations. For a compact subset "P C Ti/ , the parameter variation set P-p denotes the 
set of all piecewise continuous functions mapping 7^ (time) into V with a finite number of 
discontinuities in any interval. A compact set P C 72.*, along with continuous functions 
A-.n^ 7^nx„_ C I 72* ^ 72"'^" and D : 72* ^ 72"'>^"-^ represent an nth 

order linear parametrically varying (LPV) system, whose dynamics evolve as 


■ x{t) ■ 



B{p{t)) ■ 

■ x{t) 

. e (0 . 


. CMt)) 

D{p{t)) . 

. d{t) 


where pe P-p. For here on the time dependence of the parameter p will be suppressed due to 
space limitations. The induced £2 norm of a quadratically stable LPV system [5, 4, 7], 
with zero initial conditions, is defined as 




= sup 

pe^p 


sup 

IMIb # 0 

d G Z/2 


\\dh 


(4.2) 


This quantity is always finite. The quadratic LPV 7-performance with bounds on the pa- 
rameter rate-of- variation problem can now be stated. 


Consider a generalized plant with the usual structure 
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where the A, B, and C matrices are a function of p. For simplicity of derivation, assume 
Du{p) = 0, D 22 {p) = 0 and D^ip), D 2 i{p) have been scaled to the standard form. The LPV 
rate bounded synthesis solution can be solved as a two step procedure [5, 7], 

1. Find Necessary and Sufficient conditions for existence of a dynamic controller of 
the form 

’ 1 ^ r ^k(p,p) Bk{p,p) j r Xk 

u J [ Ck{p,p) Dk{p,p) J L 2/ . 

so that the closed-loop system passes the analysis test. 

2. In the case of one parameter, eliminate from the realization of the controller the p 
dependence. 

The analysis test is 

Definition 1 There exists a LPV controller such that the closed-loop system passes the 
analysis test if and only if there exist matrix functions V(-) and T( ) such that for all p e "P, 
X(pj,r(p)>0, and 


yi^ + iv-E(p)f 

-B^BJ YCf, 

Bi 

CnV 


0 


0 

-In, 

A^x + xA + np)f 
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The matrices A, B, C, X and Y all depend on the parameter p. where 

A{p) -.= A{p) - B2{p)Cu{p), 

B,{p) = [Bn{p) 5i2(p)], 

A{p) := A{p) - BMC2{p\ 
cj(p) = ci,(p)] . 
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The matrix functions X{-) and T( ) can be solved for by expressing the above inequalities as 
the feasibility of a set of Affine Matrix Inequalities (AMIs), which can be solved numerically. 
For more details on LPV synthesis results the reader is referred to references [5, 6, 12], 
Note that the parameter p is assumed to be available in real time, and hence it is possible 
to construct an LPV controller whose dynamics adjust according to variations in p and 
maintain stability and performance along all parameter trajectories. 

This approach allows gain-scheduled controllers to be treated as a single entity, with the 
gain scheduling achieved via the parameter-dependent controller. This approach has been 
successfully applied to the synthesis of missile autopilots [6, 17] and flight controllers [8]. 
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Chapter 5 


LPV Control Design 


LPV controllers were designed with the interconnection shown in Figure 5.1 to operate over 
the entire operating envelope. The same weights, sensor models and actuator models used 
for the second 'Hoc design are used for the LPV controller. Here P^ys changes with the 
scheduling parameter p, which we chose as a lagged measurement of power code. Using 
LPV synthesis techniques guarantees both stability and performance in the presence of time 
variations of the time-varying parameter p. The technique requires solving a linear matrix 
inequality (LMI) over the entire parameter space. 

The initial LPV designs in this chapter allow for infinity fast variations of the scheduled 
parameter p. These LPV controllers are called “non-rate bounded” designs. These may be 
inherently conservative since the controller must achieve the desired performance and robust- 
ness objectives for arbitrarily rapid changes in power code. Subsequent LPV design account 
for the physical limits on the rate-of-variation of power in the LPV synthesis process. These 
LPV controllers are called “rate-bounded” controllers. The rate-bounded LPV controllers 
are less conservative than the non-rate-bounded designs and more closely account for the 
physics of the physical system. 

The control design objective was to synthesize a LPV controller which has the same de- 
coupled command response across power code variation. The LPV controller measures the 
errors in OPR, EPR and N2 responses and schedules on power code. The resulting set of 
10 controllers, one for each operating point, contained 20 states. An induced C ,2 norm of 2.3 
was achieved. 
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Figure 5.1: LPV Control Interconnection 

5.1 LPV Control Algorithm 


Integration of the LPV controllers into the ROCETS nonlinear simulation required a new 
controller Fortran subroutine. As with the Ffoo controller algorithm, we wanted to be able to 
handle controllers of various state order, without having to recompile the simulation. Lower 
order controllers were, as with the algorithm, padded with zeros to have 21 states. The 
synthesized controllers were read in to the simulation from an external file. The controller 
entries for each point design were listed in a single column such that the 3000 Ibf thrust power 
code entry A(l,l) was the first entry and the 30000 Ibf thrust power code entry D(3,3) was 
the last entry. Figure 5.2 graphically displays the controller shape. The algorithm reads 
in the controller from the external file, assuming it contains controllers for ten operating 
points. Gains for all controllers not explicitly designed, are linearly interpolated from those 
of designed controllers. Figure 5.3 depicts an example of controller linear interpolation. Here 
controllers were explicitly designed for 6000 and 9000 Ibf power code and 5000 and 6000 ft 
altitude. The gain for 8000 Ibf, 5500 ft is easily interpolated. ^ 

The trim values of the normalized actuator commands generated from the Jacobian lin- 
earizations are added to the LPV controller commands in the ROCKET engine simulation. 
These trim values are scheduled as a function of a lagged power code measurement and 
altitude. The addition of the trim value provided the steady state control input whereas the 
LPV control signals tracking the dynamic response of the system. 

Fig. 5.4 shows 100 Ibf step response results using a single LPV controller. Comparison 
with the ?foo point designs step responses (Fig. 3.7) indicate that the LPV point controllers 
* Chris Mitchel wrote much of the LPV interpolation code 
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have similar characteristics to the Hoc counterparts. Hence we have recovered the linear 
performance and robustness of the original Hoo point design with the LPV gain-scheduled 
design while directly synthesizing a globally stable, gain-scheduled multivariable controller. 
In contrast, however, the performance of the LPV controller is guaranteed not only at the 
design points, but at intermediate values of power code as well. Moreover, implementation 
of the gain-scheduled LPV controller requires only linear interpolation of the state-space 
data. 

The LPV controller was simulated in ROCETS with power code variations the operating 
envelope (from 3000 to 27000 Ibf thrust) at sea level, standard atmosphere and zero Mach. 
Figure 5.5 shows the commanded power code variation as a function of time. Figure 5.6 
shows the plant outputs for the LPV controller and the baseline controller along with the 
requests for each. Figure 5.7 shows the plant inputs. The zoomed area in each figure provides 
a closer comparison of the LPV and baseline controllers performance. The plots indicate the 
LPV controllers reach compatible tracking, and response as the baseline controllers. This 
affirms the LPV controller synthesis methodology can achieve the same results as the more 
time-consuming ad-hoc methods traditionally used. 
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Figure 5.2: LPV Control Implementation Framework 
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Chapter 6 


LPV Controller Redesign 


This chapter describes the redesign of the LPV controller. The LPV controller described in 
the previous chapter did not perform well at high altitudes. Hence the goal of the controller 
redesign is to synthesize a single LPV controller that performs well across the flight envelope 
for all environmental conditions. The environmental conditions include a polar day (-18.5°C), 
standard day (24°C) and a tropical day (41°C). The objective is also to schedule only on 
lagged power code. Noted that above 30K ft, the actuators begin to saturate. The effect of 
these saturations will be investigated since they directly effect the achievable performance 
of the closed-loop system and potentially the stability of the system. 

n 

oo and LPV control theory are used to synthesize feedback controllers. The system 
interconnection initially considered for control design is shown in Fig. 6.2. In the figure, 
P{p) represents the three-input, three-output, three-state engine model with the scaling 
normalizing matrices (ISC and OSC) and sensor model Psen- Psen is defined as 



Figure 6.1: Turbofan engine plant model P(p) 
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VFd h-d2 



di 


Figure 6.2: Interconnection for LPV controller redesign. 

The A, B, C, D matrices vary as a function of power code (PC), with data provided for ten 
distinct power codes PC = 3000, 6000, . . . , 30000. The input and output units have been 
normalized. As mentioned previously, inputs to the plant are primary burner fuel flow rate 
(WFPRIB or PBFF, Ibm/sec), high compressor vane percentage area (VANEHPC or CVA) 
and convergent throat area feedback (AREANOZL or CVA, in^). Outputs are normalized 
overall pressure ratio (OPR), engine pressure ratio (EPR), and high rotor speed (N2). The 
PW turbofan models correspond to the identified linear model described in Section 3.1. 

The control problem is formulated as a model matching problem in the Moo and LPV 
framework. We desire the engine to respond as three single-input/single-output (SISO) 
systems with no off-diagonal coupling. Pmod represents such a decoupled system, and any 
difference between this desired model and the true plant is penalized via the weight Wp. 

The disturbance vector di represents customer demands, whose values we wish the plant 
output to track. Specifically these commands correspond to desired overall engine pressure 
ratio, engine pressure ratio and high rotor speed. The disturbance vector d .2 represents noise 
or modeling error, to which the controller should be robust. By keeping the error vector 
Cl small, good tracking of di is ensured. Input and actuator modeling errors, actuator 
magnitude and rate constraints and closed-loop bandwidth constraints are accounted for 
in the control design via the Zi to wi input/output pair. The input measurements to the 
controller is yc and the controller generates Uc as control commands. 

The actuator model Pact was derived from first principles model of the actuators in the 
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ROCETS engine simulation and system identification techniques (see Section 3.1). The 
modeling objective was to match the time response of the ROCETS engine simulation with 
the linearized actuator, sensor and engine models are power code equilibrium points. The 
actuator and sensor models were derived for the sea level, standard atmosphere and zero 
velocity flight condition. The actuator model is 
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Its realization has three states. The actuator model depicted in the Figure 6.2 outputs actu- 
ator positions u and actuator rates ii, to allow actuator rates to be penalized in the control 
design. Note that actuator associated with the convergent throat area nozzle (AREANOZL) 
is represented differently than the actuator model identified in Section 3.1. To minimize the 
number of states in the control design problem, the original first order actuator model with a 
lag is replaced by a first order transfer function model that captures the phase characteristics 
of the original two state model. 

The model-matching block Pmod was based on previous work in Reference [2]. The engine 
variables OPR and N2 are dynamically coupled based on the physics of the turbofan engine. 
Therefore the controller is designed to have the response of the engine high rotor speed (N2) 
lag the response of OPR and EPR. It is desired that the engine response to OPR and EPR 
request follow a second order model with natural frequency of 12 rad/sec and damping of 
0.85. The engine response to N2 request should follow a second order model with natural 
frequency of 2.5 rad/sec and damping of 0.85. The original engine model contained scaling 
matrices ICS and OSC whose role was to normalize the input and output signals to controller 
relative to one another. The input weight Wi is selected to be the matrix. Therefore, 
the normalized EPR, OPR and N2 commands are modeled as being of the same relative 
magnitude. 

Within the Tioo framework, the error between the desired engine response and the actual 
engine response are weighted in magnitude and across frequency via the weight Wp. The 
ideal models were derived based on the desired low frequency response of the engine. From 
a performance perspective, matching the ideal model response is more important at low 
frequency than high frequency (above 20 rad/s). Hence the performance weight Wp, which 
penalizes the difference between the desired and the actual closed-loop response of the turbo- 
fan engine, reflects the low frequency tracking accuracy desired. The larger the magnitude of 
Wp, the smaller the allowable difference between desired and actual output. In our designs. 
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Wp is a first order low-pass weight given by 

T + l 
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This ensures good tracking of the response models in the bandwidth 1-10 rad/s, with little 
or no DC error. At low frequency (below 0.1 rad/s) the Wp weight on the OPR corresponds 
to DC errors of ^ or 0.5% tracking error. The EPR and N2 tracking error at DC can be 
or 0.625%. At high frequency, the mismatch between actual and desired output is not 
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penalized. A magnitude plot of Wp is shown in Figure 6.3. 



Frequency (rad/s) 

Figure 6.3: Tracking Performance Weight Wp 


An output disturbance model is included in the controller synthesis problem formulation to 
provide robustness of the closed-loop system. The disturbance weight W^ is used to account 
for errors between the linear engine model and the nonlinear model as well as limit the 
bandwidth of control effort by ramping up at high frequency. Placing the disturbance at 
the input to the engine model would require the weight Wd to possibly vary with power 
code, as the plant gains change significantly across power code. To simplify the LPV gain- 
scheduled control design, the disturbance model is put at the plant output, where a first-order 
weight was found to be sufficient to limit controller bandwidth. We shall denote the output 


43 




disturbance weight by W^. 


Wd = 8 X 10 
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Multiplicative input uncertainty is included in the design to provide robustness to actuator 
and input uncertainty, limit the control magnitude and rate commands and limit the band- 
width of the closed-loop system. The uncertainty, modeled by A in Figure 6.2, is weighted 
on the left by VFl and on the right by ITr to balance its effect on the Hoo control design. 
Wl is a diagonal constant matrix, 1 . 76 / 3 x 3 and is a constant 3x6 matrix 




0.9/3x3 


0.23/2x2 

0 


0 

0.28 



The actuator deflections and rates are input to ITr. They are used to generate a frequency 
dependent uncertainty weight without the introduction of additional states to the design. 
Figure 6.4 shows the frequency response of the three input uncertainty weights. These 
weights imply that there is 16% uncertainty at low frequency in each input channel. At 
2.5 rad/s, the uncertainty in the first two channels has risen to 100% whereas channel three 
reaches 100% input uncertainty at 3.2 rad/s. The amount of model uncertainty is significant 
and does interact with the ability of the control design to meet the performance specifications. 
Since the uncertainty model and performance specifications are in conflict, i.e. performance 
is desired at frequencies for which the phase of the engine model is complete unknown (100% 
or more input uncertainty), the Hoc controller will not be able to achieve an infinity norm 
less than 1. The lowest achievable /{qo norm for the system for the given uncertainty weights 
H r and W\ and performance weight Wp is 5. 

"Hoc controllers are synthesized for the open-loop intereconnection shown in Figure 6.2. 
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6.1 Linear Point Designs 


Ten Hoo controllers were synthesized, one for each plant, using the interconnection of 
Fig. 6.2. The Hoo-norm achieved for these designs ranged between 5.5 and 7.9. The 7.9 

Hoo-norm is associated with the 30000 power code and the 5.5 norm is associated with the 
12000 power code. As the interconnection used has 19 states, so do each of the ten controllers. 
In this study, no attempt is made to reduce the order of the Hoo linear controllers. 

Performance objectives were evaluated in the frequency and time domain. The frequency 
analysis corresponds to the //oo-norm from d to e, which we desire to be smaller than 1. As 
noted in the previous section, there is a conflict in the level of modeling input uncertainty in 
the frequency range of 1 to 20 rad/s and the performance objectives. The performance and 
robustness requirements could not be achieved based on the problem formulation. Hence, 
Hoo-noTin values of as large as 8 were considered acceptable. The second judgment was 
made in terms of our specified objective, through inspection of step responses. Tracking 
error, decoupling, magnitude of actuator positions and rates were all evaluated in terms of 
our original goals using the nonlinear ROCETS simulation of the turbofan engine. 

The step response simulations for the linearized engine model with Tioo point design are 
shown in Fig. 6.5. Fig. 6.5 demonstrates the ability of individual controllers (one designed 
for each power code) to track the step commands. There are nine top plots in Fig. 6.5 
corresponding to the three command inputs: OPRj.gf, EPRj.gf, and N2j.gf to outputs of the 
engine model: OPR, EPR, and N2. The control design objective was to have a completely 
decoupled response from the reference commands to the engine outputs. Note that the 
dynamics of the engine vary significantly with power code. Based on the results of the 
linear, Tioc point design controllers some inherent coupling exists between the diagonal and 
off-diagonal. 
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For brevity, we will discuss the robustness analysis of three point designs at 3000, 15000 and 
30000 power codes. A plot of the magnitudes of the point design controllers is shown 
in Figure 6.6. Based on this plot, observe that the magnitude of the 'Koo point designs 
change across power code. This is consistent with the behavior of the open-loop engine 
model Jacobian linearizations. Loop-at-a-time gain and phase margins were calculated for 
all the 7^00 point design controllers. They achieved at least 27 dB of gain margin at a 
frequency of 0.5 rad/sec and 74 degrees of phase margin at a 0.5 rad/sec. Multivariable 
input and output sensitivity and complementary sensitivity plots for the Tioo controllers 
(solid lines) were calculated for the three power codes, see Figure 6.7. The input sensitivity 
and complementary sensitivity plots for the Uoo point design are excellent with peaks below 
1.3 across frequency. The output sensitivity and complementary sensitivity plots are very 
good at the low and mid power codes with peaks less than 2.2, though they degrade to 
a peak of 2.7 at 3 rad/s for the 30000 power code. This corresponds to the closed-loop 
system being robustness to 35% full block uncertainty at the output of the system. If this is 
deemed unacceptable, the weighting functions in the initial problem formulation may need 
to be modified to improve the output sensitivity and complementary sensitivity of the 
controllers at high power codes. 

Hence the closed-loop system is more sensitive to modeling errors at the output of the 
plant than the plant input. This is to be expected since the control problem formulation 
indicated that there was significantly more modeling error and uncertainty at the input to the 
plant than at the plant output. The point design controller are not meant to be scheduled 
across the operating envelope, rather the Hoo point design controller form a baseline for 
comparison with the LPV control designs. The LPV controller is designed for the entire 
operating envelope and is implemented in a nonlinear ROCETS simulation of the engine for 
testing. 
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Frequency (rad/sec) 

Figure 6.6: Magnitude frequency response at power code 3K, 15K, 30K: V .00 (solid), LPV 
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Input Complementary Sensitivity 



Output Complementary Sensitivity 



Figure 6.7: Sensitivity/complementary sensitivity at 3K, 15K, 30K: Tioo (solid), LPV 
(dashed) 
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6.2 LPV Design 


The control design objective is to synthesize a controller which has decoupled command 
response across power code variation. The flight envelope considered is sea level to 40,000 
ft with environmental conditions varying from a polar to tropical day. This LPV controller 
was synthesized using the interconnection in Fig. 6.2. The design model was based on ten 
Jacobian linearization models at sea level, zero velocity and standard atmosphere conditions. 
The same weighting functions used in the Tfoo point designs are used in the LPV design, 
though the turbofan engine model varies as a function of power code. 

The LPV controller measures the errors in OPR, EPR and N2 responses and schedules on 
a lagged measurement of power code. Recall that the commands to OPR, EPR and N2 are 
generated by an outer-loop algorithms that is part of the PW STF 952 ROCETS simulation. 
The outer-loop commands are a function of power code, flight condition, environmental 
conditions and current state of the engine. The focus of this study is tracking these commands 
since we can not directly effect them. The LPV synthesis algorithms require solving a linear 
matrix inequality (LMI) over the entire parameter space. This is an infinite dimensional 
problem. A finite dimensional LMI problem is derived by considering ten points of the flight 
envelope. Recall from the 1-L^ point designs that the "Hoo-norm varied from 5.5 to 7.9 across 
power code. To equalize the objectives across operating points, we have found it beneficial 
to normalize each point model by the inverse of its achieved linear, time- invariant i7oo-norm. 
After this scaling, each linear point design would now achieve an /foo-norm of 1. Hence, 
the induced £2 norm generated by the LPV controllers can be compared wuth the point 
designs. 

All LPV controllers were synthesized using 3-input /3-output state-space models of the 
turbofan engine starting at 3K power code (idle) up to 30K power code, military power, 
with a model every 3K. The Jacobian linearized models are used in the LPV design. A 
lookup table is constructed for the steady-state control input values as a function of power 
code and altitude. These steady-state trim inputs are added to the LPV control inputs to 
generate the actual command to the engine. The LPV controllers are synthesized using the 
/i- Analysis and Synthesis and LMI Matlab Toolbox algorithms on a Red Hat Linux computer 
with a 866 Mhz Pill processor. Both the non-rate bounded and rate bounded design include 
the time taken to limit high frequency poles of the controller. 

The non-rate bounded control design makes no assumption on the rate of variation of 
the scheduled parameter, lagged power code. In essence, it allows this parameter to vary 
infinitely fast. This may be overly conservative since the non-rate bounded LPV controller is 
required to satisfied the prescribed performance and robustness requirements simultaneously 
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at all power codes. As with the Hoc point designs, the non-rate bounded LPV controller has 
19 states. No attempt was made to reduce the state order of the non-rate bounded design. 

The induced £2 norm for the non-rate bounded LPV controller was 3.53 and took 121 CPU 
seconds to synthesize. The value of the induced £2 norm corresponds to a factor of 3.53 
degradation in the performance and robustness norms of the non-rate bounded controller 
relative to the Hoo point design results. 

The rate-bounded LPV control design directly accounts for the rate of variation of the 
scheduled parameter, lagged power code. The rate-bounded LPV design is an approximation 
of an infinite-dimensional problem as a finite-dimensional problem with a fixed set of basis 
functions. The solution to the rate-bounded controller equations are based on parameter 
dependent X and Y scalings. Three basis functions are considered to describe the X and 
Y LPV solution matrices: the constant 1, a function of power code and the square of power 
code. Denoting power code as p, the X and Y solutions matrices are: 

X{p) - X^ + pX^+p^X2 
Y{p) = Yo + pY,+p-^Y2 

Currently there is no systematic approach to the selection of basis function. Our experience 
has lead us to select basis functions that correspond to physical parameters that directly effect 
the dynamic response of the plant model within the flight envelope. Selecting power code 
and the squared of power code relates to our observations of how the linearized dynamics of 
the turbofan engine change as a function of power code. The bound on the rate-of-variation 
of power code is taken to be ±8000 /sec. 

Two non-rate and rate bounded LPV controllers are synthesized for each control problem. 
The first formulates the standard non-rate/rate bounded LPV control algorithm. The second 
uses the first solution and includes an additional constraint on the closed-loop system poles 
at the grid points. The reason for the design of the second LPV controller is that the initial 
LPV design often has very high frequency controller poles at the grid points. Since only ad 
hoc model reduction algorithms are available, which may not eliminate the high frequency 
poles, a constraint on the closed-loop system poles is added to the original LPV design 
problem, the achievable induced £2 norm is relaxed 5% from its value in the initial design 
and the LMI problem is resolved. All the LPV controllers discussed are based on the second 
LMI solution with constraints on the closed-loop poles incorporated into the LMI equations. 

For the rate bounded LPV control design, the induced £2 norm for all parameter trajecto- 
ries was 1.16. This indicates that the performance/robustness levels can be up to 1.16 times 
worse that the corresponding linear point designs. A comparison between the induced £2 
norm of the rate-bounded and non rate-bounded design indicates that the rate-bound nearly 
recovers the performance of the 'Hoc point design (normalized to a norm of 1) with a factor 
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of 3 reduction in the non rate-bounded induced norm. The rate-bounded LPV design with 
three basis functions took 3501 CPU seconds to synthesize, a factor of 30 longer than the 
non-rate bounded design. The extra computation is due to the increased number of basis 
function parameters solved in the LMI optimization. 

As with the point designs, the LPV controller has 19 states. A model reduction approach, 
based on the alignment of the LPV grid point controller eigenvectors was applied to the 
rate-bounded LPV controller. The rate-bounded controller was reduced to 12 states with 
no degradation in the induced norm or performance/robustness and could be reduced to 7 
states with little degradation. The original 19 state rate-bounded design had high frequency 
poles at the grid points on the order of 2,000 rad/sec. The reduced 12 state controller had 
its high frequency poles below 200 rad/sec and the 7 state controller had high frequency 
poles below 50 rad/sec. All analysis and simulation results presented for the rate-bounded 
controller are based on the 12 state reduced order rate-bounded LPV design. 

Fig. 6.5 (bottom figure) shows step response results using a the grid point LPV controllers 
at the equilibrium points. There is significant decoupling between the channels, though 
not quite as good as that of individual point designs. (The point designs represent the 
best we could hope to do for frozen parameter values). The poorest response in Fig. 6.5 is 
associated with the LPV controller response at the 3000 power code. In contrast, however, 
the performance of the LPV controller is guaranteed not only at the design points, but at 
intermediate values of power code as well. The implementation of the gain-scheduled LPV 
controller requires only linear interpolation of the state-space data for implementation. 

Consider the robustness analysis of the LPV evaluated at power codes 3000, 15000 and 
30000. A plot of the magnitudes of the rate-bounded LPV controller is shown in Figure 6.6. 
The magnitude of the gain-scheduled LPV design at the grid points is very similar to the 
optimal Hoc point designs. Loop-at-a-time gain and phase margins were calculated and all 
the LPV point controllers achieve at least 27 dB of gain margin at a frequency of 3 rad/sec 
and 72 degrees of phase margin at a 1.9 rad/sec. Multivariable input and output sensitivity 
and complementary sensitivity plots for the 'Hoo controllers (dashed lines) were calculated for 
the three power codes, see Figure 6.7. The input sensitivity and complementary sensitivity 
plots for the LPV grid point designs are excellent with peaks below 1.3 across frequency. 
The output sensitivity and complementary sensitivity plots are very good at the low and 
mid power codes with peaks less than 2.2, though they degrade to a peak of 2.7 at 3 rad/s 
for the 30000 power code. This corresponds to the closed- loop system being robustness to 
35% full block uncertainty at the output of the system. It is obvious from the loop-at-a-time 
gain and phase margins and Figure 6.7 that the rate-bounded LPV design recovers all the 
robustness properties of the T-L^ point design controllers w'hich is what w'as desired. 
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Example Flight Trajectory 



Figure 6.8: Power code (solid) and altitude (dashed) as a function of time 

Comparison with the Hoo point designs, linear step responses of the LPV point controllers 
indicate that the LPV point controllers have similar characteristics to the T-Loo counterparts. 
Hence we have recovered the linear performance and robustness of the original "Hoc point 
design with the LPV gain-scheduled design while directly synthesizing a globally stable, 
gain-scheduled multivariable controller. 


6.3 Linear Parameter- Varying Simulation 


The ROCETS nonlinear simulation is used to compare the baseline Pratt & Whitney con- 
troller with the LPV control designs. These simulations are performed with reference inputs 
to the power code, altitude and Mach number as a function of time. For some simulations, 
altitude and Mach number are held constant and only power code varied. Figure 6.8 shows 
the power code and altitude trajectory. Power code ranges from 3000 to 27000 and altitude 
varies from sea level to 40,000 ft. Figure 6.9 presents the candidate speed profile for the 
engine. Combined, Figures 6.8 and 6.9 represent a candidate stressful flight on the engine. 

The LPV controllers were implemented in the ROCETS simulation as discussed in Chap- 
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Candidate Mach Profile 



Figure 6.9: Speed as a function of time 

ter 2. The LPV controllers are gain-scheduled as a function of a lagged measurement of 
power code via linear interpolation. The control trim inputs, based on the Jacobian lin- 
earization, added to the LPV control inputs are scheduled as a function of lagged power 
code and altitude. The nonlinear time responses of the LPV controllers are compared with 
the baseline controller. The comparison is useful from the standpoint that the performance 
and robustness of the baseline Pratt & Whitney multivariable controller was considered very 
good by Pratt & Whitney engineers. Note that the baseline Pratt & Whitney controller was 
scheduled as a scaled function of the air flow through the engine. 

Figure 6.10 shows the response of the internal engine variables (OPR, EPR and N2) due to 
the baseline controller inputs (WFPRIB, AREANOZL and VANEHPC). Figure 6.11 shows 
normalized measurements, UIMVC, U2MVC, and U3MVC, provided to the baseline con- 
troller and the normalized outputs YlMVC, Y2MVC, and Y3MVC. Note that in Figure 6.10 
there is excellent tracking of OPR and EPR and as well as tracking of a lagged version of 
N2. These responses for the baseline for comparison with the LPV controllers. 

Figure 6.12 shows the response of the internal engine variables (OPR, EPR and N2) with 
the non-rate bounded LPV controller and Figure 6.13 shows normalized measurements and 
outputs of the controller. Note the similarity between the baseline controller commands, 
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Figure 6.10, and the non-rate bounded LPV commands, Figure 6.12. Except for the small 
transient that occurs at 1 second due to switching between the baseline controller and the 
LPV controller, the engine response is nearly identical. The same excellent tracking of OPR 
and EPR and lagged N2 is achieved. It is interesting to see that the normalized controller 
YIMVC and Y3MVC commands are very similar. Though for Y3MVC, the baseline con- 
troller commands a steady-state value of approximately 12 and the non-rate bounded LPV 
controller requests a steady-state value of approximately 2. It appears that this has little 
impact on the final N2 speed of the engine. 

Figure 6.14 shows the response of the internal engine variables (OPR, EPR and N2) with the 
rate bounded LPV controller and Figure 6.15 shows normalized mecisurements and outputs 
of the controller. Note the similarity between the baseline controller commands. Figure 6.10, 
the non-rate bounded LPV commands. Figure 6.12, and the rate-bounded LPV commands, 
Figure 6.14. The same excellent tracking of OPR and EPR and lagged N2 is achieved. The 
non-rate bounded and the rate-bounded LPV controller have very similar control commands, 
even the steady-state value of Y3MVC, though the rate-bounded LPV controller has a a low 
bandwidth. This can be observed based on the reduced level of high frequency activity 
of the normalized control signals UIMVC and U2MVC (see Figures 6.13 and 6.15). The 
reduced bandwidth of the rate-bounded LPV controller is exactly what is expected with the 
introduction of bounds on the power code rate of variation. 

The nonlinear ROCETS simulations with the LPV controllers implemented show that these 
controllers are robust to significant changes in the plant dynamics. Recall that the LPV 
controllers schedule only on lagged power code and were designed based on linearized engine 
models at zero Mach, sea level and standard day atmosphere. The candidate trajectory 
starts at sea level Mach 0.4 and reaches a peak altitude of 40,000 ft and speed of Mach 
1.2. The performance of the LPV controllers is outstanding despite the large variation in 
speed and altitude. The effect of sensor noise on the control algorithms is also of interest. 
Therefore, sensor noise is added to the normalized measurements, UIMVC, U2MVC and 
U3MVC prior to the controller receiving these signals. 

Figures 6.16 and 6.17 show the response of the engine and controller variables with a 
small amount (approximately 10%) of sensor noise on control input. The rate bounded LPV 
controller is implemented in the ROCETS nonlinear simulation. There is no degradation of 
the excellent tracking performance of the controller. Increasing the sensor noise to over 40%, 
shown in Figures 6.18 and 6.19 leads to some degradation of the tracking performance though 
the overall tracking performance is still adequate. Hence the rate-bounded LPV design is 
very insensitive to small amounts of sensor noise as well as changes in the plant dynamics. 
For comparison. Figures 6.20 and 6.21 show the response of the baseline controller with over 
40% sensor noise. The baseline design is slightly more sensitive to the large amount of sensor 
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noise than the rate-bounded LPV controller. 


Similarly, there is no change in the tracking performance of the rate-bounded LPV con- 
troller due to temperature fluctuation. Compare the response of the LPV controller on a 
standard day, Figures 6.14 and 6.15, with the response on a polar day. Figures 6.22 and 6.23, 
and a tropic day. Figures 6.24 and 6.25. Hence, the rate-bounded LPV controller is robust 
to significant variations. 

The tracking performance of the LPV controller is perhaps better illustrated by holding the 
speed constant at zero Mach, standard atmosphere and a constant non-zero altitude. Power 
code is varied as a function of time. Figures 6.26 and 6.27 show the response of the non-rate 
bounded LPV controller at sea level. This compares well with the rate-bounded LPV design 
at sea level. Figures 6.28 and 6.29. Figures 6.30, 6.31, 6.32 and 6.33 show the engine and 
rate bounded LPV controller time responses at 15,000 and 30,000 ft altitude respectively. It 
is obvious that the engine dynamics change dramatically as a function of altitude. 
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Figure 6.14: Engine response for 
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Figure 6.16: Engine response for candidate flight with small sensor noise: Rate Bounded 
LPV Controller 
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Figure 6.18; Engine response for candidate flight with large sensor noise: Rate Bounded 
LPV Controller 
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Figure 6.22: Engine response for candidate 
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Figure 6.24: Engine response for candidate flight tropical day: Rate Bounded LPV Controller 
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Figure 6.28: Engine response for sea level flight: Rate Bounded LPV Controller 
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Figure 6.32: Engine response for 30K ft altitude flight: Rate Bounded LPV Controller 

















Chapter 7 


Summary 


Recent advances in robust control synthesis for LPV systems were applied to a high fidelity, 
nonlinear simulation of a turbofan engine under this research program. The control objective 
was to decouple the multivariable system into three independent channels with minimal 
cross-coupling, subject to actuator magnitude and rate limitations. "Hoo point designs 
provided an initial starting point, giving an indication of the performance which might be 
expected of an LPV controller. After obtaining reasonable point designs, an LPV controller 
was synthesized and its performance evaluated. 

The nonlinear ROCETS simulation of the Pratt & Whitney engine with the LPV controllers 
implemented achieved excellent tracking of the command signals with small magnitude ac- 
tuator commands. The rate- bounded LPV controller were robust to significant variations in 
the engine model dynamics, atmospheric conditions and sensor noise. Excellent tracking per- 
formance was achieved it all scenarios except in the presence of large sensor noise. Although 
the synthesis of LPV controllers are computationally more intensive than individual linear 
point designs, the guaranteed and actual performance and robustness of the gain-scheduled 
LPV designs indicate the benefit of the rate-bounded LPV control designs far out weighs 
their computation time expense. 
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Appendix A 


User’s Guide 


A.l Introduction 

This Appendix is intended to be used as a user’s manual for the UNIX script files, Matlab 
M files, and the modified SCIP transient engine simulations used in this work. The reader 
interested in details of the SCIP transient engine simulation is directed to [1]. 


A. 2 Nonlinear Simulation 

To simplify the operation of the nonlinear simulation, a series of UNIX script files were 
written. They run the correct files and rename the input and output files more descriptively 
then the simulation does alone. The file rimorig runs the original program provided to the 
University or Minnesota. The file runptdes reads in a point-design controller to replace the 
Pratt & Whitney controller in the simulation. The file runlpv reads in a LPV controller to 
replace the Pratt & Whitney controller. It is assumed in the following discussions that these 
script files are being used. These script files are discussed further in Section A. 4. 

The original and modified versions of the SCIP transient engine simulation read an input file 
containing all run parameters, and generate four output files. The input file must end with 
the extension “.dat” . For example filename . dat is an acceptable name. Three of the output 
files are automatically named filename . output , filename .run in, filename . errors. The 
name of the fourth output file is chosen by the user in filename .dat. The files f ilename .runin, 
filename . errors record errors in reading and processing the input file and can be used for 
trouble-shooting. The file filename . output, also referred to as the “print file”, can be 
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used to look at specific data points, and holds any generated linear models. The fourth file 
contains the data suitable for plotting in Matlab. It is often referred to as the “plot file” . 

Although the input files are thoroughly discussed in [1], a quick tutorial is provided on the 
most relevant aspects to this work in terms of an example contained in section A. 3. 

The input file is organized in seven blocks of similar function type. The blocks are 
named SCHEDULES, INPUTS, RESTART, OUTPUT, INTEGRATION, EXCEPTIONS, 
and BALANCE EXCEPTIONS. Each block is started with a DEFINE command and ended 
with an END command. 

DEFINE (block type) 

END (block t3rpe) 

The blocks are read into the simulation in a top-down fashion, so the user must sequence 
the blocks accordingly. 


A.A.2.1 SCHEDULES 

The SCHEDULES block is used to define univariant or bivariant curves representing func- 
tional relationships for the model. The curves can be functions of time or steady state point. 
The example file defines a schedule called SCHFGR. It is a schedule of thrust (XFCFGR) 
with time. The schedule data is listed in standard map reader format; the first two entries 
are zero, the third and forth indicate the number of data points of the first and second 
independent parameters. The remaining entries are data of the first independent parameter, 
the second independent parameter, and the dependent parameter respectively. The example 
file’s schedule is univariant with time. It has a total of eight data points. Hence the third 
entry is “8.0” and the forth is “0.0” . 

The simulation assumes ramps between each defined point, so a step input can be approx- 
imated by placing points close together. In the example, a 200 Ibf step is defined at 21.00 
seconds. The input power code schedule, along with the output OPR, is plotted in Figure 
A.l. 

A.A.2.2 INPUTS 

The INPUTS block is used to define all inputs to the simulation. The example defines the 
altitude (ft), mach number, side slip (degrees), and angle of attack (degrees) to be zero. It 
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defines the engine face static pressure to be 14.696 psi. The thrust is referenced to the 
schedule defined in the preceding SCHEDULES block as SCHFGR. 


A.A.2.3 RESTART 

The RESTART block is used to specify a value for the GUESS routine in the simulation. 
As in the example file, “0.0” is normally used. 


A.A.2.4 1st OUTPUT 

The OUTPUT block defines the parameters the simulation is to record in its output files. The 
example file tells the simulation to record all the data points of OPR, EPR, N2, OPRREQ, 
EPRREQ, N2REQ, and XFCFGR. It instructs the simulation to print them to a file called 
test .data. 

A.A.2.5 1st RUN 

The RUN block provides the simulation with general information on the type of run required. 
The first RUN block in the example file tells the simulation to run one point to steady state 
using a maiximum of of 200 iterations. 


A.A.2.6 BALANCE EXCEPTIONS 

The BALANGE EXCEPTIONS block is used to turn on or off simulation balances. 


A.A.2.7 2nd OUTPUT 

The 2nd OUTPUT block in the example file turns off printing to the print file (the . output 
file in our case). 

A. A. 2. 8 2nd RUN 

The 2nd RUN block in the example file runs a transient simulation and writes the data 
requested in the OUTPUT block every 0.05 seconds. It stops the simulation at 30 seconds, 
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no matter what is provided in the SCHEDULE block or elsewhere in the input file. 


A. A. 2. 9 Hints 

• There is a limit as to how many data points can be plotted in a run. If the simulation 
runs, but the plot file has only recorded a single data point, although you instructed 
otherwise, try increasing the plot time so you’re not asking for as many points. 

• While writing input files. Do not use tabs. Only use spaces. 

• A * in the first column indicates a comment line 


A. 3 Example input file 


*<DEBUG> 


★ ♦ 

* SCIP TRANSIENT ENGINE MODEL (CCD1453-00 . 0) * 

* * 

* EXAMPLE FILE * 

* * 

* * 


* 4c »c i|c :<c ****««« 4c >4c :«c>|c :|n4c >tc* :4c * >tc ** >tc « >«c *** * Itntc itc ^ 4: HcHc >)c ])c * >)c ** »c * >)c ** iK ************ * 

DEFINE SCHEDULES 

* 

* THRUST REQUEST TO ENGINE CONTROL AS A FUNCTION OF TIME 

* 

SCHEDULE: SCHFGR IS XFCFGR = F(TIME ) ; 

SET SCHEDULE: SCHFGR= 0.0, 0.0, 8.0, 0.0, 

0.00, 5.00, 9.5, 12.5, 19.00, 21.00, 

21.01, 30.0, 

27000.0, 27000.0, 27100.0, 27100.0, 26900.0, 26900.0, 

27100.0, 27100.0; 

* 

END SCHEDULES 

4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4t 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4t 4c 4c 4c 4c 4c 4t 4c 4c 4c 4c 4c ** 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 4c 

* INPUTS * 
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* 

DEFINE INPUT 

* 


* FLIGHT CONDITION 

ALT = 0.0, 

XM = 0.0 

* 

* FLIGHT CONTROL INTERFACE 

* 

XFCFGR = SCHEDULE SCHFGR 
XFCAOA =0.0 

XFCBET =0.0 

XFCPO = 14.696 , 

XFCMNL =0.0 

♦ 

lENGCON = 1 ; 

♦ 

END INPUT 

********l|e*!|C***5|t*j)C***j)t*l)t:)t!(t**!t!!(t:(tj(C 

* CALL FIRST GUESS ROUTINE ♦ 

DEFINE RESTART 
GUESS =0.0; 

END RESTART 

* OUTPUT OPTIONS ♦ 

:tc3*c*3*cj*c5<c:|c5|c:^s»c:t:3jca|c*3*c***3tejt{3»cj*c:<e + 3|es|c:|£:^e 

DEFINE OUTPUT 


STEADY-STATE PRINT : 

OFF ; 

TRANSIENT PRINT 

OFF ; 

PRINT : 

ALL, ; 

PLOT : 

ALL, 


OPR, EPR, 


YIMVC, Y2MVC 


N2, 

Y3MVC, 


OPRREQ, EPRREQ, N2REQ, 


XFCFGR; 
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PLOT FILE 
PLOT TITLE 


test. data ; 
EXAMPLE FILE DATE; 


END OUTPUT 

♦ ♦ 
sK)♦c♦♦♦♦♦♦♦♦♦♦3♦c:ic + JttJ^eJ»eJ^eJ»£a^C3♦c:♦c3♦c♦3^cJ♦c3♦c3^c3^c:♦c3^cs^cs^c:^c3♦cJ|e5^CJ|c)♦c)^^)|cs|e3^£3♦^3♦^*J»cJ^cJ»c*3♦c:♦£5^c5^c^♦c:♦e3^C3♦e♦3♦e♦*>♦c>K♦♦♦♦* 

DEFINE RUN 

STEADY STATE : POINTS =1., MAXPASS = 200; 

END RUN 

****************************************** 

* TURN OFF STEADY STATE ENGINE CONTROL BALANCES * 

:(t***%J(t***** ********* ***>(1**1*:* ******* ******♦*♦♦♦♦♦♦♦*♦**♦ 


DEFINE BALANCE EXCEPTIONS 

ACTIVATION FOR AN0ZLBL2 OFF 

ACTIVATION FOR WFPRBBL2 ; OFF 

ACTIVATION FOR WFAB1BL2 OFF 

ACTIVATION FOR WFAB2BL2 : OFF 

ACTIVATION FOR WFAB3BL2 : OFF 

ACTIVATION FOR VNHPCBL2 : OFF 

ACTIVATION FOR VNFANBL2 OFF 

ACTIVATION FOR VNECSBL2 : OFF 

ACTIVATION FOR QDOTEHEX OFF 

END BALANCE EXCEPTIONS 


******************************************************* 

* TURN OFF PRINT OUTPUT (PLOT OUTPUT IS STILL ON) ♦ 
******************************************************* 

DEFINE OUTPUT 

PRINT : NOPRINT ; 

END OUTPUT 

*********************** 

♦ RUN THE TRANSIENT * 

*********************** 

DEFINE RUN 

TRANSIENT: DT = .0125 , PRINT TIME=5.0, PLOT TIME=0.05, 
STOP TIME= 30.00 ; 

END RUN 
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Figure A.l: Power Code and Plant output (P4/P2) from Example File 


A. 4 UNIX script files and Matlab M files 

A. A. 4.1 runorig 

The script file rimorig is used to run the original simulation. After creating an input file as 
explained in Section A. 2 type 

mcix7, runporig filename 

This will run the simulation, creating the four output files. 

A. A. 4. 2 runptdes 

The script file runptdes can be used to run a single point controller. Suppose a point design 
controller in a /i tool system matrix format named sys is to be tested in the nonlinear 
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simulation. The first step is to convert the controller into a Kblock format. This can be 
done using the matlab function sys2Kblock.m. The resulting matrix should then be saved 
in ascii format to a file named Kblock. 

» Kblock=sys2Kblock(sys ,f 21) ; 

» save -ascii Kblock Kblock ; 

The next step is to create an input file as described in Section A. 2. If the input file is named 
filename.dat, the nonlinear simulation can be run by typing 

max*/, rimptdes filename 

This will run filename.dat using the controller contained in the file Kblock. Note that 
runptdes only runs on sun4 architecture, and Kblock must be in the same directory as 
test.dat. 


A. A. 4. 3 runlpv 

To run a LPV controller scheduled on power code in the nonlinear simulation, the script file 
runlpv can be used. The LPV controller must be in a ascii column format as detailed in 
the paper, and saved as LPVdata. 

>> save -ascii LPVdata lpv_controller ; 

An input file, as outlined in Section A. 2, can then be run with runlpv. For example, if the 
input file is named filename.dat 

max*/, runlpv filename 

Note that LPVdata must be in the same directory as test.dat. 


A. A. 4. 4 data2m.m 

Once a nonlinear simulation has been run, the data in the plot file can be easily loaded in 
matlab with data2m.m. The syntax is 

[m,names]=data2m(dataf ile,flag) ; 
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Here datafile is a string containing the name of the data file. Flag is either “time” 
or “point”. If your simulation was a time response and saved in f ileneime .data,use the 
command 

» [m, names] =data2m( ’filename . data’ , ’time ’ ) ; 

If your simulation was scheduled as something other than time and saved in filename . data, 
use the command 

»[m, names] =data2m( ’filename, data’ , ’point’) ; 

The matrix names contains the names of all variable contained in the varying matrix m. 

A. A. 4.5 engplot.m 

Once data from a data file had been loaded into Matlab, it can be plotted with engplot. 
For example if the data matrix m contains data for OPR, you can use the command 

»engplot(m, names , ’DPR’ ) ; 


A. 5 Plant Linearization 

Linear plants can be created by the nonlinear simulation with a LINEARIZATION block in the 
input file. As before, 1 will illustrate usage with an example file. The file can be found in 
section A. 6 

The blocks used for linearization follow the same format as those described above. Two 
blocks, LINEARIZATION and LINEARIZATION EXCEPTIONS define the linearization to be per- 
formed. Typically the base point about which linearization is desired, is defined through a 
steady state run 

DEFINE RUN 

STEADY STATE : POINTS =1., MAXPASS = 200; 

END RUN 
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A.A.5.1 INTEGRATION DEFAULTS and EXCEPTIONS 


The states are controlled through the INTEGRATION DEFAULTS and EXCEPTIONS 
blocks and the balances through the BALANCE DEFAULTS and EXCEPTIONS blocks. 


DEFINE INTEGRATION EXCEPTIONS 

ACTIVATION FOR SN2 : STEADY STATE ; 

ACTIVATION FOR PTECHD : STEADY STATE ; 

ACTIVATION FOR TTECHD ; STEADY STATE ; 

ACTIVATION FOR SNECS : STEADY STATE ; 

ACTIVATION FOR PT65 ; STEADY STATE ; 

END INTEGRATION EXCEPTIONS 
DEFINE BALANCE EXCEPTIONS 

ACTIVATION FOR AN0ZLBL2 OFF 

ACTIVATION FOR WFPRBBL2 : OFF 

ACTIVATION FOR WFAB1BL2 OFF 

ACTIVATION FOR WFAB2BL2 ; OFF 

ACTIVATION FOR WFAB3BL2 : OFF 

ACTIVATION FOR VNHPCBL2 : OFF 

ACTIVATION FOR VNFANBL2 : OFF 

ACTIVATION FOR VNECSBL2 : OFF 

ACTIVATION FOR QDOTEHEX : OFF 

END BALANCE EXCEPTIONS 


A.A.5.2 LINEARIZATION PRINT 

The LINEARIZATION PRINT option must be turned on in the OUTPUT block 
DEFINE OUTPUT 

LINEARIZATION PRINT : ON ; 

END OUTPUT 


A.A.5.3 LINEARIZATION 

The LINEARIZATION block is used to define the inputs and outputs of the desired linear 
model. 
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DEFINE LINEARIZATION 

INPUTS : WFPRIB , AREANOZL, VANEHPC; 

OUTPUTS : PT2, PT4, PT6, SN2; 

END LINEARIZATION 

A. A. 5. 4 Output file 

The resulting A,B, C, and D matrices are written to the output file. These matrices can 
be automatically loaded into matlab using output2sys.m (see section A.A.7.1). Note the 
nonlinear simulation may return error messages in the output file. These errors can generally 
be ignored, because of a known error checking problems with the program. 


A. 6 Example linearization input file 

DEFINE INPUT 

* FLIGHT CONDITION 

ALT =0.0 

XM =0.0 

♦ FLIGHT CONTROL INTERFACE 


XFCFGR 

= 3000 , 

XFCAOA 

= 0.0 

XFCBET 

= 0.0 

XFCPO 

= 14.696 , 

XFCMNL 

= 0.0 

lENGCON 

= 1 


END INPUT 

DEFINE RESTART 
GUESS =0.0; 
END RESTART 


DEFINE OUTPUT 


PRINT 

DUMPALL 

STEADY-STATE PRINT : 

OFF 

TRANSIENT PRINT 

OFF 

PLOT : 

ALL, 
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WFPRIB, AREANOZL, VANEHPC 


PT2, PT4, PT6, SN2; 

PLOT FILE : tmp.data ; 

PLOT TITLE : LINEARIZE ; 

END OUTPUT 

DEFINE RUN 

STEADY STATE : POINTS =1., MAXPASS = 200; 
END RUN 

DEFINE INTEGRATION EXCEPTIONS 


ACTIVATION 

FOR 

SN2 

: STEADY 

STATE 

ACTIVATION 

FOR 

PTECHD 

: STEADY 

STATE 

ACTIVATION 

FOR 

TTECHD 

: STEADY 

STATE 

ACTIVATION 

FOR 

SNECS 

: STEADY 

STATE 

ACTIVATION 

FOR 

PT65 

: STEADY 

STATE 


END INTEGRATION EXCEPTIONS 


* TURN OFF STEADY STATE ENGINE CONTROL BALANCES ♦ 

DEFINE BALANCE EXCEPTIONS 


ACTIVATION FOR AN0ZLBL2 : OFF 

ACTIVATION FOR WFPRBBL2 OFF 

ACTIVATION FOR WFAB1BL2 OFF 

ACTIVATION FOR WFAB2BL2 OFF 

ACTIVATION FOR WFAB3BL2 ; OFF 

ACTIVATION FOR VNHPCBL2 : OFF 

ACTIVATION FOR VNFANBL2 : OFF 

ACTIVATION FOR VNECSBL2 OFF 

ACTIVATION FOR QDOTEHEX : OFF 

END BALANCE EXCEPTIONS 


DEFINE OUTPUT 

LINEARIZATION PRINT : ON ; 

END OUTPUT 

DEFINE LINEARIZATION 

INPUTS : WFPRIB , AREANOZL, VANEHPC; 
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OUTPUTS ; PT2 , 
END LINEARIZATION 


PT4 , PT6 


SN2; 


DEFINE LINEARIZATION EXCEPTIONS 

NORMALIZER FDR VANEHPC : 100.0 ; 
END LINEARIZATION EXCEPTIONS 


DEFINE BALANCE EXCEPTIONS 

ACTIVATION FOR AN0ZLBL2 : OFF 
ACTIVATION FOR WFPRBBL2 : OFF 
ACTIVATION FOR VNHPCBL2 : OFF 
ACTIVATION FOR VNFANBL2 : OFF 
ACTIVATION FDR VNECSBL2 ; OFF 
ACTIVATION FOR WFAB1BL2 : OFF 
ACTIVATION FOR WFAB2BL2 : OFF 
ACTIVATION FOR WFAB3BL2 ; OFF 
ACTIVATION FOR QDOTEHEX : ON 
END BALANCE EXCEPTIONS 


DEFINE RUN 
LINEARIZE : ; 
END RUN 


A.7 MORE UNIX SCRIPT and MATLAB files 

A. A. 7.1 output2sys.m 

The Matlab M file output2sys.m reads the linearized plant from the simulation output file 
to generate a system matrix. If the output file is named filename .output, for example, the 
following command will create a system matrix names sys 

» sys=output2sys(’filename’) ; 


97 



A. A. 7.2 linearize 


The UNIX script file linearrize can be used to generate the plant models at 3000, 6000, 
9000, . . . 30000 Ibf thrust by replacing the line 

XFCFGR = 3000 , 


in the input file with 

XFCFGR = <INSERT_P0INT> 


The script replaces <INSERT_P0INT> with the values listed in the ascii file points generating 
a series of linearized plant models. 

For example, to create a series of linearized plants at sea level, the INPUT block should have 
the form 

DEFINE INPUT 
* FLIGHT CONDITION 


ALT 

= 0.0 

XM 

= 0.0 

FLIGHT CONTROL INTERFACE 

XFCFGR 

= <INSERT_PDINT> 

XFCAOA 

= 0.0 

XFCBET 

= 0.0 

XFCPO 

= 14.696 , 

XFCMNL 

= 0.0 

lENGCON 

= 1 

lENGCON 

= 0 


END INPUT 

The file points is the simple ascii file: 

3000 . 0 

6000 . 0 

9000 . 0 

12000.0 

15000.0 

18000.0 
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21000.0 

24000.0 

27000 . 0 

30000 . 0 


Appendix B 


FORTRAN Source Code 


This appendix contains the FORTRAN subroutines written for this project. Small explana- 
tions are included before each. 


B.l Point Design Implementation 


This section contains the FORTRAN code written to implement point design controllers into 
the nonlinear simulation. 


B.B.1.1 compute_state 

The subroutine compute_state is called by the larger simulation. It, in turn, calls all the 
other subroutines which read in the controllers and updates the controller states and outputs. 


Subroutine compute_state(FGRREQ,CRCYBl, CRCYB2, CRCYB3,Ulin, 
& U2in, U3in, Ylout, Y2out , Y3out) 

C FORMAL PARAMETERS 

REAL Ulin, U2in, U3in 


REAL Ylout, Y2out, Y3out 
REAL Ylouta, Y2outa, Y3outa 
REAL FGRREQ 
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REAL Min (24,1), Mout(24,l) 

REAL P(72,8) 

REAL A (24, 24) 

REAL St (21) 

REAL Ylbase, Y2base, YSbase 
Integer counter 

save St, counter, A 
data (St(i), i=l ,21)/21*0.0/ 
data counter /O/ 
count er=counter+l 

if (counter .eq. 1) then 
CALL GETMXA8(P,72) 

Call REF0RMMX(P,72,8,A,24,24) 

end if 

C— MULTIPLY ACROSS THE CONTROLLER 

Do 11 i=l,21 

Min(i , l)=St (i) 

11 Continue 

Min(22,l)=Ulin 
Min(23,l)=U2in 
Min(24, l)=U3in 

CALL MULTMX ( A , 24 , 24 , Min . 24 , 1 , Mout ,24,1) 

Do 22 i=l,21 

St(i) = Mout(i,l) 

22 Continue 

Ylouta = Mout (22,1) 

Y2outa = Mout (23,1) 

Y3outa = Mout (24,1) 

CALL linterp(CRCYBl,FGRREQ, Ylbase) 
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CALL 1 int erp ( CRCYB2 , FGRREQ , Y2base ) 
CALL lint erp (CRCYB3 , FGRREQ ,Y3base) 

Ylout = Ylouta + Ylbase 
Y2out = Y2outa + Y2base 
Y3out = Y3outa + Y3base 

RETURN 

END 


B.B.1.2 linterp 

The subroutine linterp is used to linearly interpolate between two points. The vector T 
contains x-y data in standard mapping format. A value of x is input as Xin and linterp 
returns the corresponding value of y in Yout. 

Subroutine linterpCT, Xin, Yout) 

C PURPOSE 

C Linearly Interpolate between points on a function f(x). 

C Given point on f (x) , linterp returns f(x) for any value of x. 

C 

C 

C SYNTAX 

C CALL linterpCT, Xin, Yout) 

C 

C T : Data in PW’s mapping format (which could be called with tabx2) 

C 

C Vcoriables passed in: 

DIMENSION T(=*=) 

REAL Xin, Yout 
C Internal Variables : 

REAL nx,n 

REAL X(10), Y(IO) 
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500 


600 


C 

C 


INTEGER i 

REAL X_high, X_low, Y.high, Y_low 
nx = T(3) 

Do 500, n=l,nx 
X(n)=T(4+n) 

Y(n)=T(4+n+nx) 

CONTINUE 

if (Xin.lt .X(D) then 

Yout=Y(2)-(Y(2)-Y(l))/(X(2)-X(l))*(X(2)-Xin) 
elseif (Xin.gt .X(nx)) then 

Yout=Y (nx-1 ) + (Y (nx) -Y (nx-1 ) ) / (X (nx) -X (nx-1) ) * (Xin-X (nx-1) ) 


else 

i=l 

if (Xin.gt .X(i)) then 
i=i+l 
go to 600 
end if 

X_high=X(i) 

X_low =X(i-l) 

Y_high=Y(i) 

Y_low =Y(i-l) 

*/, 2nd: Linerly interpolate the exact value 

7. the ratio xf cfgr/(pchigh-pclow) = opr/(oprhihg-oprlow) 

Yout=(Xin-X_low)/(X_high-X_low)*(Y_high-Y_low) + Y_low 


endif 

END 
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B.B.1.3 GETMXA8 


The subroutine GETMXA8 reads in the controller from a file named Kblock. It inputs the 
number of rows to read (r). It returns the matrix read as a r x 8 column matrix A. 

SUBROUTINE GETMXA8(A,r) 

REAL cl, c2, c3, c4, c5, c6, c7, c8 
Integer r 
REAL A(r,8) 

INTEGER n 


n=0 

OPEN (Unit=15, File= ’Kblock' , STATUS= ’ OLD ’ ) 

123 READ (15,124,END=125) cl, c2, c3, c4, c5, c6, c7, c8 

124 F0RMAT(2X,E14.7,2X,E14.7,2X,E14.7,2X,E14.7, 

& 2X,E14.7,2X,E14.7,2X,E14.7,2X,E14.7) 

n=n+l 

A(n,l) = cl 
A(n,2) = c2 
A(n,3) = c3 
A(n,4) = c4 
A(n,5) = c5 
A(n,6) = c6 
A(n,7) = c7 
A(n,8) = c8 
GOTO 123 

125 n=0 
CL0SE(UNIT=15) 

RETURN 

END 


B.B.1.4 REFORMMX 

The subroutine REFORMMX reforms the matrix A (read in by GETMX8) into the correct three 
input, three output, 21 state format. 
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SUBROUTINE REFORMMX ( A , R1 , Cl , B , R2 . C2) 

C THIS SUBROUTINE REFORMS THE 72 by 8 matrix into a 24 by 24 
INTEGER Rl, R2, Cl, C2, BL, R, C, BLOCKS, AR 
REAL A(R1,C1) 

REAL B(R2,C2) 

BL0CKS=R1/R2 

Do 2 BL=1, BLOCKS 
Do 3 R=1,R2 

Do 4 C=1,C1 

BC=C+C1*(BL-1) 

AR=R+R2*(BL-1) 

B(R,BC)=A(AR ,C) 

4 Cont inue 

3 Continue 

2 Continue 


RETURN 

END 


B.B.1.5 MULTMX 


The subroutine MULTMX inputs the matrices A and B along with their dimensions, and returns 
the product of A • i? in the matrix C. 

SUBROUTINE MULTMX (A , AROW , ACOL , B , BROW , BCOL . 
k C,CR0W,CC0L) 

C 

C THIS SUBROUTINE MULTIPLIES ARRAYS A AND B AND STORES RESULT AS C 
C 

INTEGER AROW , ACOL , BROW , BCOL , CROW , CCOL , I , J , K 
REAL A (AROW, ACOL) ,B (BROW, BCOL) ,C (CROW, CCOL) 

LOGICAL ERROR 

ERRORS .FALSE. 

IF (ACOL. NE. BROW) ERROR = .TRUE. 
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IF (AROW.NE.CROW) ERROR = .TRUE. 

IF (BCOL.NE.CCOL) ERROR = .TRUE. 

IF (ERROR) THEN 

PRINT*, ’ERROR IN THE ARRAY SIZES’ 
Stop 
ELSE 

DO 30 1=1, CROW 
DO 25 J=1,CC0L 
C(I,J) = 0.0 

DO 15 K=1,AC0L 

C(I,J) = C(I,J) + A(I,K)*B(K,J) 
15 CONTINUE 

25 CONTINUE 
30 CONTINUE 
ENDIF 
RETURN 
END 


B.2 Power Code LPV Implementation 

B.B.2.1 compute_state 


The LPV Implementation, as with the point design code, uses computejstate as it’s main 
routine and calls all other subroutines from it. 


Subroutine compute_state(FGRREQ, CRCYBl, CRCYB2, CRCYB3, Ulin, 
& U2in, U3in, Ylout, Y2out, Y3out) 


C FORMAL PARAMETERS 

REAL Ulin, U2in, U3in 
REAL OREQ, EREQ, NREQ 
REAL Ylout, Y2out, Y3out 
REAL Ylouta, Y2outa, Y3outa 
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REAL FGRREQ 


REAL Min(33,l). Mout(33,l) 
REAL A (33, 33) 

REAL St (30) 

C YBASE VARIABLES 


REAL Ylbase, Y2base, Y3base 


save St 

data (St(i), i=l,30)/30*0.0/ 


CALL GETMXA (FGRREQ, A) 


C— MULTIPLY ACROSS THE CONTROLLER 

Do 11 i=l,30 

Min(i,l)=St(i) 

11 Continue 

Min(31,l)=Ulin 

Min(32,l)=U2in 

Min(33,l)=U3in 

CALL MULTMX (A , 33 , 33 , Min , 33 , 1 , Mout ,33,1) 


Do 22 i=l,30 

St(i) = Mout(i,l) 

22 Continue 

Ylouta = Mout (31,1) 

Y2outa = Mout (32,1) 

Y3outa = Mout (33,1) 

CALL 1 int erp ( CRCYB 1 , FGRREQ , Y 1 base ) 
CALL 1 interp (CRCYB2 , FGRREQ , Y2base ) 
CALL 1 interp (CRCYB3 .FGRREQ ,Y3base) 
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Ylout = Ylouta + Ylbase 
Y2out = Y2outa + Y2base 
Y3out = Y3outa + Y3base 

RETURN 

END 


B.B.2.2 GETMXA 

The subroutine GETMXA accepts a powercode as input and returns the linearly interpolated 
controller for that powercode. 

SUBROUTINE GETMXA ( PC, B IGA) 

* THIS IS THE LPV SUBROUTINE 

* This subroutine reads in a location within a given power code matrix to 
♦find percent values of the four corners around it. Then new A,B,C and D 
♦matricies are computed from these percent values. If the location 
♦given does not fall within the power code matrix the subroutine will 
♦not run and will return a value of ingrid=0. 

* 

♦ Required input to subroutine: 

* 

♦ G - Gigantic matrix, power code and altitude matrix organized 

♦ left to right, top to bottom such that all power codes 

♦ at a given altitude run consecutively. Also single colximn 

♦ so single matircies A through D also run across the rows. 


* 

ex 

[G] = [[A] WHERE 

1 — 1 
> 
1 — 1 

II 

t — 1 
»-*• 
!-»• 



[B] 

(1,2) 

* 


[C] 

(1,3) 

* 


[D](1,D 


* 


[A] 


* 


[B] 

(2,1) 



[C] 

(2,2) 

* 


[D] (1,2) 
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* PC - POWER CODE 

* VEC - power code and altitude matrix (WAT2) 

* il - length of PC vector (3,6,9,12,15,18,21,24,27,30) so 10 

* 

* Output of subroutine: 

* 

* ingrid - returns 1 if located within WAT2 matrix and 

* returns 0 if not located within WAT2 matrix and stops 

* A,B,C,D - new matricies computed from G 

* 

* Temporary variables : 

* 

* S - temporary matrix not passed through 

♦ alpha - percent location of WAC2 between points 

c 

integer nr ,nc ,nx,ny ,nu, il , i , j ,tl ,bl , ii , j j ,nt 
parameter (il= 10 ,nx=30,ny=3 ,nu=3) 
real A(30,30) ,B(30,3) ,C(3,30) ,D(3,3) 
real alpha, Stmp( 1089) , VEC (10) ,BIGA(33,33) 
real PC, temp 
real G( 10890) 

Integer counter 

C ReadLPV VARIABLES 

Integer nxtrue 
Real LPVin( 10890) 

save counter, G 
data counter /O/ 
count er=counter+l 



nc=nx+nu 

nr=nx+ny 

♦ 

♦ Get PC vector 

♦ 

VEC(1)= 3000.0 

VEC(2)= 6000.0 

VEC(3)= 9000.0 

VEC(4)= 12000.0 
VEC(5)= 15000.0 
VEC(6)= 18000.0 
VEC(7)= 21000.0 
VEC(8)= 24000.0 
VEC(9)= 27000.0 
VEC( 10) =30000.0 

* 

* Logic function to meike temp in bounds 

* 

temp=PC 

if ( PC . LT . VEC ( 1 ) ) t emp=VEC ( 1 ) 
if ( PC . GT . VEC ( i 1 ) ) t emp=VEC ( il ) 

* 

* READ in G (found through ReadLPV aind PadLPV) 

* 

if (counter . eq. 1) then 

Call readlpv(nxtrue,LPVin) 

Call padLPV(nxtrue,LPVin,G) 

endif 

* 

* Find contributions of each side aind calculate staurt auid end 

* point of first matrix (tl=top limet, bl= botom limit) 

* 

alpha=0 . 0 
do 20 i=l,il-l 

if (temp. GE.VEC(i) .AND. temp. LE.VEC(i+l))then 
if (temp . NE . VEC ( i ) ) then 
alpha= (t emp-VEC ( i ) ) / ( VEC ( i+1 ) -VEC ( i ) ) 


no 



end if 

tl=nr*nc*(i-l)+l 
bl=nr*nc*i 
goto 30 
end if 

20 continue 

* 

* Compute new A,B,C, euid D matricies 

* 

30 nt=nr*nc 

ii=0 

do 40 i=tl,bl 
ii=ii+l 
c 

Stmp(ii)=G(i)+alpha*(G(i+nt)-G(i)) 

c 

40 continue 

c Maike A 

ii=0 

do 60 i=l,nx 


do 50 j=l,nx 
ii=ii+l 

A(i, j)=Stmp(ii) 
50 continue 
60 continue 

c Make B — 

ii=nx*nx 


do 80 i=l,nx 


do 70 j=l,nu 
ii=ii+l 

B(i, j)=Stmp(ii) 
70 continue 
80 continue 

c Make C 

ii=nc*nx 


do 100 i=l,ny 
do 90 j=l,nx 
ii=ii+l 
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C(i, j)=Stmp(ii) 
90 continue 
100 continue 
c Madce D 


i i=nc *nx+nx *ny 
do 120 i=l,ny 


do 110 j=l,nu 
ii=ii+l 

D(i, j)=Stmp(ii) 

110 continue 
120 continue 
* 

* Make it one large matrix 

* 


do 123 i=l,nx 
jj=nx 

do 121 j=l,nx 
BIGA(i,j)=A(i,j) 

121 continue 

do 122 j=l,nu 

BIGA(i,jj)=B(i,j) 

122 continue 

123 continue 
c 

ii=nx 

do 126 i=l,ny 
jj=nx 
ii=ii+l 
do 124 j=l,nx 
BIGA(ii,j)=C(i,j) 

124 continue 

do 125 j=l,nu 

BIGA(ii,jj)=D(i,j) 

125 continue 

126 continue 
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end 


B.B.2.3 padLPV 

The subroutine padLPV inputs the LPV vector read in by readlpv along with the number 
of states of the LPV controller, and returns a LPV vector that has been padded with zeros 
so that all controllers have 30 states. 

C 

C This subroutine rearreinges LPVin by moving the zeros 
C according to nx. (Largest possible is 30 states, 10 pc vec) 

C 

Subrout ine padLPV (nx , LPV in , LPV out ) 


Integer nx, i, j, loc , locin, pclength 
Real LPVin(10890) , LPVout (10890) 


pclength=10 

loc=0 

locin^O 

Do 99 k=l, pclength 


C A 

Do 1 i=l,30*(30-nx) 
loc=loc+l 
LPVout ( loc )=0 
1 Continue 

Do 2 i=l,nx 

Do 21 j=l,30-nx 
loc=loc+l 
LPVout (loc)=0 
21 Continue 

Do 22 j=l,nx 
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loc=loc+l 
locin=locin+l 
LPVout (loc)=LPVin(locin) 
22 Continue 

2 Continue 


C B 

Do 3 i=l ,3*(30-nx) 
loc=loc+l 
LPVout (loc)=0 

3 Continue 

Do 4 i=l,nx*3 
loc=loc+l 
locin=locin+l 
LPVout (loc)=LPVin(locin) 

4 Continue 

C C 

Do 5 i=l,3 

Do 51 j=l,30-nx 
loc=loc+l 
LPVout (loc)=0 

51 Continue 

Do 52 j=l,nx 
loc=loc+l 
locin=locin+l 
LPVout (loc)=LPVin(locin) 

52 Continue 

5 Continue 

C D 


Do 6 i=l,9 
loc=loc+l 
locin=locin+l 
LPVout (loc)=LPVin(locin) 
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6 


Continue 


99 Continue 
End 

C END subroutine 

B.B.2.4 readLPV 

The subroutine readlpv reads in the LPV vecctor from an external file named LPVdata and 
returns it along with the number of states contained in each of the vectors controllers. It 
assumes there are a total of 10 controllers in the LPV vector. 


C 

C This subroutine reads in the LPV controller from LPVdata 
C It must be called before compute_state b/c it provides the 
C number of states to be used in compute_state 
C (Assumes PCvec length of 10, Max number of states=30) 

C 

Subrout ine readlpv (nxi , LPV ) 

Integer num, nxi, counter 

Real LPV(10890), LPVlocal (10890) , nx 

save coimter, LPVlocal, nx 

data counter /O/ 
counter=counter+l 

if (coimter. eq. 1) then 
num=0 

9 OPEN (Unit=19, File= 'LPVdata’ , STATUS= ’ OLD ' ) 

num=num+ 1 

READ(19,10,end=ll) LPVlocal (num) 

10 F0RMAT(2X,F14.7) 
go to 9 

11 CLOSE (UNIT=19) 
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end if 


nx=sqrt (real (num/10) ) -3 
nxi=int (nx) 

do 12 i=l,num 

LPV(i)=LPVlocal(i) 

12 continue 

END 

C END subroutine 

The LPV implementation also calls the subroutines linterp and mutlmx which are listed 
in the Point Design section above. 


B.3 Compilation 


The full engine simulation consists of three FORTRAN files and an assortment of auxiliary 
files containing common data blocks. The main files are 


ccdl453_eng_con . f 
ccdl453jnain.f 
ccdl453jroc_util .f 
ccdl453_eng_mod . f 
ccdl453jroc_run . f 

The auxiliary files need are 

CLCASCOM 

CLCCOM 

ECSCASCOM 

ECSCCOM 

NCCCOM 

NCCOM 

NCSCOM 

SHRCCOM 
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To compile the program with a new control algorithm copy in into ccdl453_eng_con.f . For 
example, if the new control algorithm was in a file named newcontrol .f , type 

cp newcontrol. f ccdl453_eng_con.f 

Then run the makefile on a sun4 architecture by typing 

'/.max make 

This runs the UNIX script file Makefile . sun4. It was written to compile, and link all the 
components. 
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Appendix C 


Line by Line Example 


This Appendix lists the specific commands to run a ROCETS simulation using 

• The PW simulation 

• A point design simulation 

• A LPV simulation 

Note that this Appendix is strictly intended for those working in Dr. Gary Balas’ lab who 
have access to the Sun machines max and/or marlowe. At this point, the ROCETS simula- 
tions only run on sun4 architecture. The example files are located at /home/res6/ j ackryan/pwf 1/Examp 
These directions are also located at /home/res6/ j ackryan/pwf 1/Examples/HowToRun. txt. 

Before running the following examples, type the line 

/Cmax set path=(/home/res6/jackryan/Script /home/res6/jackryan/pwf 1/PwScripts $path) 

It adds the path which contains all the necessary UNIX script files. Also add the paths 

» path ( Vhome/res6/j ackryan/pwf 1/m’ .path) ; 

» path ( ’/home/res6/j ackryan/pwf 1/m/MeikeModel ’ .path) ; 

>> path( ’/home/res6/jackrycin/pwfl/m/TestModel ’ .path) ; 

in Matlab. They contain all the necessay Matlab M files. 
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C.l The original Pratt Sz Whitney simulation 


To run the original Pratt & Whitney simulation, go to the directory /home/res6/jackryan/pwf 1/Exampl 
and type 


max’/, pwd 

/home/res6/jackrycui/pwf 1/Examples 
max’/, runorig example 
Running example (sun4 version) . . 
max’/. 


It creates the files 


example . errors 
example . runin 


example . output 
fort . 25 
test .data 


: Contains any error messages if any occurred 
: a filtered copy of example.dat which is 
sent to the program. Lists .dat file errors 
the end (good for trouble shooting) 

: values of a single point in the run 
: a link to example.dat 

: The plot file. Lists all the data of the rxm. 


Now load and plot the data into Matlab by typing the commands at a Matlab prompt 


» [m, names] =data2m( ’test .data’ , ’time’) ; 
First line of data: 10 
Number of data points : 722 

Reading variables: 

TIME EPR EPRREQ FGR N2 N2REQ 

OPR OPRREQ WAC2 XFCFGR XFCFGR YIMVC 

Y2MVC Y3MVC 


Number of variables found: 14 
» engplot (m, names , ’EPR’ , ’EPRREQ ’ ) ; 
The variable EPR is is ambiguous. 
Using the first occurrence of EPR 
» print -deps epr_plotl 
» 
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C.2 Running a Point Design 


Now run the Point Design version. The file Kblock contains a point designed controller. 
The controller must be in a file named Kblock. First move test, data to test . orig . data 
so that the PW simulation results are not over-written. 

max*/, mv test, data test .Ipv. data 
max*/, runptdes example 
R unn ing example (sun4 version) . . 
max*/. 

In Matlab, load and plot the new data 

» opr_plot (m,mp, names , ’EPRO ; 

The variable EPR is is ambiguous. 

Using the first occurrence of EPR 
The variable EPR is is ambiguous. 

Using the first occurrence of EPR 
» print -deps epr_plot2 
» 


C.3 Running a LPV Design 

Now run the LPV version. LPVdata contains the LPV controller; the program looks for 
LPVdata so the controller must have this name. First move test .data to test . orig. data 
so the results from the point design simulation will not be over-written 

max*/, mv test, data test . orig. data 
max*/, runlpv example 
Running example (sun4 version) . . 
max*/. 

In Matlab, load the new data and plot the new and old together 

>> [ml .names] =data2m( 'test . data' , 'time' ) ; 

First line of data: 10 
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Number of data points: 722 


Reading variables: 

TIME EPR EPRREQ FGR N2 N2REQ 

OPR OPRREQ WAC2 XFCFGR XFCFGR YIMVC 

Y2MVC Y3MVC 

Number of variables found: 14 
» opr_plot(m,ml,names, ’EPR’ ) ; 

The Vciriable EPR is is ambiguous . 

Using the first occurence of EPR 
The variable EPR is is ambiguous. 

Using the first occurrence of EPR 
» print -deps epr_plot3 
» 

All files used and created in these examples are contained in /home/res6/jackryan/pwf 1/Examples/. 

There are a few more executables (all located in /home/res6/jackryan/puf 1/PwScripts/) 
which have not been specifically mentioned. They are run in the same fashion as listed above. 

They are 

runorig Runs the original ROCETS 

rimptdes Run a point design controller 

runlpv Run an LPV controller scheduled on power code 

rimlpvl Run an LPV controller scheduled on lagged power code 

rvmtemp Used to run temporary codes for testing (I just use it 

for ease ... it’s not necessary) 

All the FORTRAN source code used in this project is located at 

/home/res6/jackryan/pwf 1/ src/ 

The various control algorithm source code files are listed and described below 
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lpv_lag.f 

jack_ml_eng_con . Ipv . f 
j ack_ml_eng_con . Ipv2d . f 
jack_ml_eng_con.ptdes .f 
wac2 . lag . Ipv . new . f 
wac2.1pv.new.f 


LPV code which schedules on lagged PC 
(run with runlpvl) 

LPV code scheduled on PC 
(run with rimlpv) 

LPV code scheduled on 2 variables 
(In a proof of concept stage) 

Point Design code (reads in Kblock) 
(run with runptdes) 

LPV code scheduled on filtered WAC2 
(run with runwacl) 

LPV code scheduled on WAC2 
(run with runwac) 
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